Mac OS® X provides prior art graphics and imaging frameworks for developers to create “views” for graphical user interfaces (GUIs) of a computer application. (MAC OS is a registered trademark of Apple Inc. of Cupertino, Calif.). For example, Cocoa is an object-oriented application environment that developers can use to develop Mac OS X native applications. Apple's Cocoa Application Framework (also referred to as Application Kit or AppKit) is one of the core Cocoa frameworks. Application Kit provides functionality and associated Application Programming Interfaces (APIs) for applications, including objects for graphical user interfaces, event-handling mechanisms, application services, and drawing and image composition facilities.
NSView is part of Cocoa's Objective-C API and is an abstract class that defines basic drawing, event-handling, and printing architecture of applications. With NSView, each “view” of an application's GUI is dealt with using local coordinates, and each view is positioned relative to its parent view in a hierarchical fashion. Using a view hierarchy is useful for building complex user interfaces out of modular parts. The Application Kit framework is used to develop NSView-based applications. This framework contains objects needed to implement a graphical, event-driven user interface that includes windows, dialogs, buttons, menus, scrollers, text fields, etc. Application Kit framework handles the drawing of objects, communicates with hardware devices and screen buffers, clears areas of the screen before drawing, and clips views.
GUIs for computer applications have increased in complexity and are usually designed to handle views, animations, videos, windows, frames, events, etc. Even with the increased complexity, the goal of developers is to make the GUIs more tactile and natural in appearance. Accordingly, developers must consider how to create and manage the GUIs for computer applications with this goal in mind.
Referring to FIG. 1A, a rendering process 100 according to the prior art is schematically illustrated. In the rendering process 100, an application 110, which can be based on NSView as discussed above, inputs GUI information into a backing store 120 and issues rendering commands to the render engine 130. The render engine 130 renders the GUI information from the backing store 120 into a frame buffer 140. The render engine 130 can use Apple's Core Image and Core Video. Core Image is an image processing framework, and Core Video is a video processing framework. Scan-out hardware 150 then outputs the rendered information in the frame buffer 140 to a display 160 using a frame rate 180 of the display 160.
This prior art rendering process 100 has no built-in framework for animating objects or views. Instead, the NSView-based application 110 handles animation explicitly by moving views around, resizing views, etc. To provide animation, most NSView-based applications 110 developed in the art resort to using “snapshots” of the views and compositing the snapshots using other facilities. In FIG. 1A, the application 110 is show having a pseudo-code loop 112 for animating movement of an object or view for the application's GUI. In this simplified example, the object or view is being moved from a start point A to an end point B (e.g., the application 110 may receive user input moving a view from a starting position on the display to an ending position). The typical developer of the application 110 does not want the object to disappear from point A on the display 160 and suddenly appear at point B on the display 160 because users prefer a more gradual or “natural” movement.
To make the movement more gradual or “natural,” the developer of the application 110 typically animates the movement of the object from start point A to end point B using explicit code such as code segment or loop 112. In this simplified code, the loop 112 is used to animate the object by incrementally moving the object some distance X for each iteration of the loop 112. FIG. 1B shows some resulting positions of an object or view 164 as it would appear incrementally on displayed results 162 as the application 110 of FIG. 1A performs the animation of the object 164 with the iterative loop 112 of FIG. 1A. The number of steps or “snapshots” used to animate the movement of the object 164 is decided by the developer. In addition to such an iterative loop 112 for moving objects, the developer must include explicit code in the application 110 to implement any form of animation (e.g., fade-in, fade-out, resize, etc.) for an object.
In addition to requiring explicit animation in the application 110, the data structures and painting model for NSView present problems when the application 110 has dynamic content. For example, NSView makes no particular distinction between changes in content and layout and is not well tuned for continuous re-layout. As a NSView object is moved, for example, it creates “damage” to content in its wake that requires other views to be redrawn. Redrawing a view typically invokes the model-to-view mapping code of NSView-based application 110 and requires expensive computations to be performed (particularly if the model data needs to be retrieved over a network).
The timing of services for this form of application 110 offers some additional difficulties for developers. Most animations are done using one or more timers (e.g., the embedded loops or iterative steps 112) in the main event loop of the application 110. Therefore, the duty cycle of the timer for the animation is completely dependent on how fast the application 110 services its main event loop. Although some events can be handled quickly, other events may take much longer and may actually be subject to I/O delays.
In addition, the frame buffer 140 and scan-out hardware 150 operate under a frame rate 180 to output information to the display 160. The frame rate 180 is typically about 60-Hz. To improve the handling of events, developers attempt to operate the application 110 in synchronization with the frame rate 180 of the hardware. In this way, the majority of events of the application 110 can be timely handled within the main loop of the application 110 and rendered to the display 160 at the frame rate 180. However, maintaining such a consistent frame rate of 60-Hz. in the main loop of the application 110 can be difficult. Furthermore, determining what actual frame rate to use and determining when to initiate the timer to keep it in sync with video blanking of the scan-out hardware 150 is not readily apparent in a given context because the application 110 is not given intimate knowledge of the video display 160 and its associated hardware 150.
In addition to presenting problems for developers with respect to animation and event handling, the NSView-based application 110 may have problems related to layout of the GUI for the application 110. For example, a number of constraints must typically be applied to views when they are resized for display. One of the views may have a fixed absolute size, while other views may be designed to change size with the composition. Additionally, many views (e.g., text or web views) must explicitly change how they are represented as a function of the actual size at which they are to be displayed. Consequently, the text or web view may need to invoke its own layout techniques when it is resized. Developers of the NSView-based application 110 must explicitly handle these types of complex issues.
The subject matter of the present disclosure is directed to overcoming, or at least reducing the effects of, one or more of the problems set forth above.